iT邦幫忙

2026 iThome 鐵人賽

DAY 19
0
Claude AI

用 AI Agent 重構一套無框架的 legacy PHP 系統系列 第 19

Day 19:從「被使用者糾正」到「記住規則」——feedback 記憶怎麼運作

  • 分享至 

  • xImage
  •  

前言:記住「使用者不喜歡什麼」,真的有用嗎?

「AI 被糾正過的事情,記下來下次不要再犯不就好了嗎?」

聽起來理所當然,但真正動手設計這套記憶機制時,會發現「記下來」這三個字藏著一個陷阱:記的是「使用者不喜歡什麼」,還是「使用者為什麼不喜歡、在什麼情境下才適用」? 這兩種記憶表面上都叫「feedback」,但只有後者真的有用——前者只會讓 AI 在下一次類似但不完全相同的情境裡,套錯規則。

今日目標

  • 理解「記住使用者不喜歡什麼」跟「記住為什麼不喜歡」之間的關鍵落差
  • 看兩個真實案例:一個是被反覆糾正才真正記住,一個是被否決後記下完整的判斷邏輯
  • 建立 feedback 記憶該包含哪些要素的具體標準
  • 認識這套機制怎麼跟 Day 17 講過的 skill 化流程接上

淺層記憶 vs 深層記憶:一個具體對照

先看一個真實發生過的案例。AI 曾經判斷某個功能「目前流量沒觸發,可以不用當成 bug 處理」,被使用者直接否決。如果只記下「使用者否決了這個判斷」,這條記憶幾乎沒有用——下次遇到「流量小」的情境,AI 完全不知道這條記憶適不適用,因為它根本沒記下否決的理由。

❌ 淺層記憶:
「使用者否決了『流量小不算 bug』這個判斷,下次不要這樣說。」
→ 只記住結論,沒記住判斷邏輯。下次遇到看起來相似但情境不同的
  狀況(例如流量小,但影響的是資料正確性而不是使用者體驗),
  AI 沒有依據判斷這條記憶適不適用,可能誤套用、也可能誤以為不適用

✅ 深層記憶:
「AI 用『目前流量沒觸發』當理由判定某功能不是 bug,被使用者否決。
  否決的理由是:流量小只代表『還沒有人踩到』,不代表『踩到了沒有影響』——
  這個功能的問題是資料寫入邏輯本身有缺陷,不是使用情境的問題。
  這條教訓後來被寫進對應的 skill,明確要求『分頁查詢』這類邏輯
  即使目前流量沒有觸發分頁上限,也要按照正確設計實作,不能用
  『反正現在用不到』當理由簡化。」
→ 記住判斷邏輯、否決理由、適用邊界,下次遇到類似情境
  可以正確判斷這條記憶要不要套用

這個對照差異的核心是:淺層記憶只保留了「使用者的情緒反應」,深層記憶保留的是「使用者糾正背後的判斷邏輯」——只有後者才能被正確地遷移到新情境。

反覆被糾正同一件事,才會真正記住

feedback 記憶還有一個更難處理的現象:有些教訓不是被否決一次就記住的,而是被反覆糾正好幾次才意識到問題出在哪。

有一個真實例子:使用者連續四次反映同一個問題——AI 寫程式碼時習慣加上大量說明性註解。前三次,AI 都只是「這次少寫一點」,但沒有真正搞清楚問題的根源。直到第四次被提起,AI 才回頭查證 CLAUDE.md 跟既有的專案規範,發現根本沒有任何規則要求要寫這些註解——這純粹是 AI 自己的慣性,不是規則要求,也不是這個專案的需要。

這件事值得記下來的重點不是「使用者不喜歡註解太多」,而是:AI 有些行為模式是慣性造成的,不是被規則驅動的,這種慣性只有在被反覆指出之後,才會被真正意識到、進而修正。 記憶系統面對這種情況,不該只記「這次被糾正了什麼」,而要記「這是第幾次被糾正同一件事」——出現在同一件事上的重複次數,本身就是一個訊號,代表這不是單一情境的例外,而是需要被寫進更上層規則(例如 CLAUDE.md 或 skill)的系統性問題。

feedback 記憶該包含哪些要素

綜合這兩個案例,一條有用的 feedback 記憶,至少要包含:

  1. AI 原本的判斷邏輯是什麼——不只是「AI 做錯了什麼」,而是「AI 當時是怎麼推理出這個結論的」
  2. 使用者否決/糾正的具體理由——不是「使用者不喜歡」,是「為什麼不喜歡、錯在哪個環節」
  3. 這條教訓適用的情境邊界——什麼情況下這條規則成立,什麼情況下不成立,避免下次被過度套用或錯誤套用
  4. 是否已經被提煉進更上層的規則——如果這條教訓已經寫進 skill 或 CLAUDE.md,要標注清楚,避免同一個問題被重複討論一次

沒有這四個要素的 feedback 記憶,本質上只是一句抱怨的存檔,不是可以指導未來判斷的規則。

跟 skill 化流程怎麼接上

Day 06 講過的一個案例裡,那條規則的來源之一,正是一次被使用者當場否決的判斷——「流量小不算 bug」被否決之後,不只是存進個人的 feedback 記憶,而是進一步被提煉成一支 skill 裡的明確要求。這正是這套記憶系統設計上最重要的分工:feedback 記憶負責記住「這一次」發生了什麼、為什麼;當同一類教訓反覆出現、或者影響範圍夠廣時,才值得往上收斂成 skill 裡的規則,讓下一次不需要重新經歷一次被糾正的過程。

這也呼應了 Day 01 立下的主題句:AI 給出的判斷之所以危險,不是因為它笨,而是因為它的自信範圍常常比它實際驗證過的範圍大。feedback 記憶要做的,就是誠實記下「這個範圍曾經被驗證過是錯的」,並且記清楚錯在哪個具體維度——這樣下次同一個維度出現時,AI 才有機會提前意識到自己可能又要犯同一種錯。

今日思考題

回想你上一次糾正 AI 的判斷:如果請它把這次糾正寫成一條記憶,它會寫下「我不能這樣做」,還是會寫下「我當時的推理邏輯是什麼、你否決的理由是什麼、這條教訓在什麼情境下才適用」?前者跟後者的差別,就是這條記憶下次到底有沒有用的關鍵。

今日重點回顧

  • feedback 記憶不是記「使用者不喜歡什麼」,是記「AI 原本的判斷邏輯」加上「否決的具體理由」加上「適用邊界」
  • 只記結論的淺層記憶沒辦法正確遷移到新情境,容易誤套用或誤以為不適用
  • 有些問題不是被糾正一次就會修正,是被反覆指出同一件事之後才會被意識到是系統性慣性,不是單一例外
  • feedback 記憶跟 skill 化流程要接上:反覆出現、影響夠廣的教訓,要往上收斂成 skill 規則,不能只停留在個人記憶層級

明日預告

明天要講記憶系統的另一個真實風險:記憶本身會過期。上次查證的結果、上次記下的現況,可能在今天已經不再成立——怎麼判斷一條記憶還能不能信,是明天的主題。


上一篇
Day 18:AI 的持久記憶系統——user/feedback/project/reference 四種記憶類型
下一篇
Day 20:記憶會過期——怎麼避免 AI 依賴已經失效的舊資訊
系列文
用 AI Agent 重構一套無框架的 legacy PHP 系統21
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言